上一篇提到，要深入瞭解需求，需要大量的溝通，對應到 DDD 中非常重要的一環——與領域專家一同開會。理想情況是，聚集所有利害關係人，透過事件風暴確認需求後再開發，但實際執行會遇到一些問題。

事件風暴效率低？

對工具還不熟悉時，事件風暴動輒就是1、2小時起跳，安排多人的長時會議不容易，更難辦的是人多嘴雜，往往最後仍沒有達成共識。

除了多練習事件風暴的流程，另一種解法是，透過對領域專家的訪談，來了解他們的想法，再由開發團隊（包括實作人員 ）收斂成規格與實作細節，最後再去確認共識。雖然一樣耗時耗人力，但在討論的過程，開發者不但能針對程式中不符合領域專家想像的邏輯或概念進行優化，新開發的功能也能更加有效的解決問題。

沒有領域專家該怎麼辦呢?

不是每個需求都會有對應的領域專家，尤其在新創團隊，新的商業模式沒有可參考的案例，甚至是仍在探索階段。

以團隊的經驗而言，讓開發者越早和需求者開始溝通可以降低成本；因為開發者可以從另一個角度幫助需求者釐清領域，也可以在心中先有個底。

而從程式架構的角度來看的話，有幾個可以遵循的原則：

• 變動機率高的地方（需求越不確定、或是越重要）架構設計越彈性
• 延後決策

下篇會回顧導入 DDD 後專案是否有改進。